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                    Infrastructure ENUM Requirements

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document provides requirements for "infrastructure" or "carrier"
   ENUM (E.164 Number Mapping), defined as the use of RFC 3761
   technology to facilitate interconnection of networks for E.164 number
   addressed services, in particular but not restricted to VoIP (Voice
   over IP.)
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1.  Infrastructure ENUM

1.1.  Definition

   Infrastructure ENUM is defined as the use of the technology in RFC
   3761 [1] by the carrier-of-record (as defined below) for a specific
   E.164 number [2] to publish the mapping of the E.164 number into a
   URI [3] that identifies a specific point of interconnection to that
   service provider's network.  It is separate from any URIs that the
   end user, who registers their E.164 number, may wish to associate
   with that E.164 number.
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   "Infrastructure ENUM" is distinguished from "End User ENUM", defined
   in RFC3761 [1], in which the entity or person having the right to use
   a number has the sole discretion about the content of the associated
   domain and thus the zone content.  From a domain registration
   perspective, the end user number assignee is thus the registrant.
   Within the infrastructure ENUM namespace, we use the term "carrier-
   of-record" for the entity having discretion over the domain and zone
   content and acting as the registrant.  The "carrier-of-record" is:

   o The Service Provider to which the E.164 number was allocated for
   end user assignment, whether by the National Regulatory Authority
   (NRA) or the International Telecommunication Union (ITU), for
   instance, a code under "International Networks" (+882) or "Universal
   Personal Telecommunications (UPT)" (+878) or,

   o if the number is ported, the service provider to which the number
   was ported, or

   o where numbers are assigned directly to end users, the service
   provider that the end user number assignee has chosen to provide a
   Public Switched Telephone Network/Public Land Mobile Network (PSTN/
   PLMN) point-of-interconnect for the number.

   It is understood that the definition of carrier-of-record within a
   given jurisdiction is subject to modification by national
   authorities.

1.2.  Background

   Voice service providers use E.164 numbers currently as their main
   naming and routing vehicle.  Infrastructure ENUM in e164.arpa or
   another publicly available tree allows service providers to link
   Internet-based resources such as URIs to E.164 numbers.  This allows
   service providers, in addition to interconnecting via the PSTN/PLMN
   (or exclusively), to peer via IP-based protocols.  Service providers
   may announce all E.164 numbers or number ranges they host, regardless
   of whether the final end user device is on the Internet, on IP-based
   open or closed Next Generation Networks (NGNs), or on the PSTN or
   PLMN, provided that an access point of some type to the destination
   service provider's network is available on the Internet.  There is
   also no guarantee that the originating service provider querying
   infrastructure ENUM is able to access the ingress network element of
   the destination provider's network.  Additional peering and
   accounting agreements requiring authentication may be necessary.  The
   access provided may also be to a shared network of a group of
   providers, resolving the final destination network within the shared
   network.
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2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC2119 [4].

3.  Requirements for Infrastructure ENUM

   1.  Infrastructure ENUM SHALL provide a means for a provider to
       populate DNS resource records (RRs) for the E.164 numbering
       resources for which it is the carrier-of-record in a single
       common publicly accessible namespace.  The single common
       namespace ultimately designated may or may not be the same as
       that designated for End User ENUM (e164.arpa.)  The Fully-
       Qualified Domain Name (FQDN) in the resulting resource records
       will not necessarily belong to or identify the carrier-of-record.

   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return a result, even if the result is Refused (RCODE = 5).
       Queries must not be rejected without response, e.g., based on
       access control lists.

   3.  Infrastructure ENUM SHALL support RRs providing a URI that can
       identify a point of interconnection for delivery to the carrier-
       of-record of communications addressed to the E.164 number.

   4.  Infrastructure ENUM SHOULD be able to support an Internet
       Registry Information Service (IRIS) [5] capability that allows
       qualified parties to obtain information regarding the E.164
       numbering resources and the corresponding carrier-of-record.
       Determination of what information, if any, shall be available
       which parties for geographic numbers is a national matter.

   5.  Implementation of infrastructure ENUM MUST NOT restrict the
       ability of an end user, in a competitive environment, to choose a
       Registrar and/or name server provider for End User ENUM
       registrations.

   6.  The domain name chosen for infrastructure ENUM and any parent
       domains MUST be hosted on name servers that have performance
       characteristics and supporting infrastructure that is comparable
       to those deployed for the Internet root name servers.  Those name
       servers for infrastructure ENUM should be configured and operated
       according to the guidelines described in [6].

   7.  Infrastructure ENUM MUST meet all reasonable privacy concerns
       about visibility of information over which an end user has no
       control.  It should, for example, support mechanisms to prevent
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       discovery of unlisted numbers by comparison of ENUM registrations
       against directory listings, or inadvertent disclosure of user
       identity.

   8.  Proposed implementations of infrastructure ENUM SHOULD:

       A.  Minimize changes required to existing requirements that are
           part of RFC 3761.

       B.  Work with open as well as closed numbering plans.

       C.  Not require additional functionality of resolvers at large
           though they may require additional functionality in service
           provider resolvers that would make use of infrastructure
           ENUM.

       D.  Minimize the number of lookups required to obtain as many
           NAPTR (Naming Authority Pointer) records (end user and
           infrastructure) as possible.

       E.  Minimize knowledge of the numbering plan required of
           resolvers making use of Infrastructure ENUM.

       F.  Maximize synergies with End User ENUM.

       G.  Support interworking with private ENUM trees.  (In this
           context, a private ENUM tree is one that is not under
           e164.arpa or whatever namespace is chosen for infrastructure
           ENUM but uses instead a privately held domain.)

4.  Security Considerations

   Existing security considerations for ENUM (detailed in [1]) still
   apply.  Since infrastructure ENUM involves carriers where RFC 3761
   mainly considered indviduals, implementations meeting these
   requirements SHOULD reconsider the RFC 3761 security model given this
   difference in actors concerned.  Note that some registration
   validation issues concerning End User ENUM may not apply to
   infrastructure ENUM.  Where the Tier 1 registry is able to identify
   the provider serving a number, e.g., based on industry data for
   number block assignments and number portability, registration might
   be more easily automated and a separate registrar not required.

   Some parties have expressed concern that an infrastructure ENUM could
   compromise end user privacy by making it possible for others to
   identify unlisted or unpublished numbers based on their registration
   in ENUM.  This can be avoided if providers register all of the their
   allocated (as opposed to assigned) numbers.  Unassigned numbers
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   should be provisioned to route to the provider's network in the same
   fashion as assigned numbers and only then provide an indication that
   they are unassigned.  In that way, provider registration of a number
   in ENUM provides no more information about the status of a number
   than could be obtained by dialing it.

   Implementers should take care to avoid inadvertent disclosure of user
   identities, for example, in the URIs returned in response to
   infrastructure ENUM queries.

5.  IANA Considerations

   This document includes no actions to be taken by IANA.  The
   architecture ultimately chosen to meet the requirements may require
   IANA actions.
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